✨ Fiche d'Aide à la Décision
Document interactif — Tout s'ouvre directement dans le navigateur
Document Word Original
Visualisation du document DOCX converti en HTML. Tout le contenu est éditable.
FAD
-
DOCUMENT D’ANALYSE FONCTIONNEL
-
FUNCTIONAL ANALYSIS DOCUMENT
Processus Achat
Microsoft Business Central
- ANAL
Sommaire
4. Traitement d‘une livraison directe 6
5. Saisie d’une demande de prix 7
6. Saisie d’une commande cadre 8
7. Saisie d’une commande d‘achat 10
8. Saisie d’un retour d’une commande achat 12
11. Annexe 1 : Liste d‘écarts 16
Ce document liste l’analyse fonctionnel sur les processus métier du client concernant le domaine des achats. Les principaux objectifs de l’analyse fonctionnel sont :
- Visiter les sites clients comme les usines, entrepôts et/ou bureaux
- Conduire des ateliers orientés processus.
- Ne pas rentrer en profondeur sur les fonctionnalités de l’ERP ni faire de démonstrations
- Comprendre la façon de travailler actuelle, les points faibles et les attentes globales et futures
- Identifier les écarts critiques et les interfaces qui peuvent avoir un impact sur le projet
- Identifier les volumes des référentiels et données transactionnelles
- Confirmer le périmètre fonctionnel, technique, géographique et organisationnel du projet
- Identifier un jeu de donnée nécessaire pour l’ERP pour mieux préparer les ateliers de démonstration.
Ce document a été préparé sur la base d‘atelier(s) réalisés avec les membres de l'équipe de projet suivants :
Atelier | Date | Lieu | Almakom | Client |
1er atelier | … | … | Nom et Prénom | Nom et Prénom |
2ème atelier | … | … | Nom et Prénom | Nom et Prénom |
Versions du document
Version | Date | Description | Ecrit par | Approuvé par |
Draft | JJ/MM/AAAA | Draft | Nom et Prénom | Nom et prénom |
… | JJ/MM/AAAA | … | … | … |
Membre de l‘équipe | Fonction | |
Nom et Prénom | … | … |
Nom et Prénom | … | … |
Les processus standards ERP qui font partie des ateliers d’analyse sur les achats sont :
3 Planification
3.1. Contexte et Hypothèses
**3.1 Contexte et Hypothèses**
Le processus d'achat du client Almatech est complexe et implique plusieurs types d'achats, notamment les offres, les projets et les achats génériques de la société. Les achats sont mutualisés multi-projet, ce qui signifie que les besoins des différents projets sont gérés de manière centralisée.
**Types d'achats**
Il existe trois types d'achats :
* Offres (devis) : les offres sont demandées avant de passer à la commande.
* Projets (demande d'achat) : les besoins des projets sont anticipés ou constatés et les achats sont effectués au niveau de chaque projet.
* Achats génériques société (licences, ordinateurs...) : les achats génériques sont effectués pour les besoins de la société en général.
**Processus de réception**
Le processus de réception des pièces est complexe et implique plusieurs étapes :
* Réception des pièces : les pièces sont reçues physiquement au bureau de l'EPFL.
* Contrôle qualité : un contrôle qualité léger ou approfondi est effectué par le chef de projet ou l'ingénieur.
* Inspection systématique : pas d'inspection systématique à la réception.
* Photos des colis : chaque colis reçu est pris en photo.
* Rattachement à la commande : les pièces sont rattachées à la commande correspondante.
**Fonctionnalités souhaitées**
Les fonctionnalités souhaitées dans le système sont :
* Suivi de la confirmation de commande fournisseur.
* Date de livraison renseignée dans le système.
* Intégration des coûts de transport lié à la commande.
* Gestion des statuts pour bloquer la facture en comptabilité si la qualité n'est pas validée.
**Référentiel fournisseur**
Le référentiel fournisseur est important pour gérer les lead times fournisseurs, les différents plannings (fournisseur, transport, Almatech) et la classification des produits.
**Devis et commande**
Le devis est lié à la commande et les champs suivants sont utilisés :
* Due Date
* Requested Receipt Date
* Numéro de projet obligatoire sur le devis pour lier la commande au projet.
**Commande (Make Order)**
La commande est liée au devis et les champs suivants sont utilisés :
* Numéro de projet et tâches projet à renseigner sur les lignes pour permettre la consommation sur le projet.
* Gestion des Incoterms : utilisation du champ Shipment Method Code.
**Réception (détaillée)**
La réception est effectuée à l'aide du Warehouse Receipt avec visibilité sur :
* Référence
* Quantité
* Rattachement à la commande
**Contrôle qualité**
Le contrôle qualité est effectué à l'aide d'un document de contrôle qualité avec rattachement de photos, tracking lot et série.
**Projet**
Les lignes budget sont utilisées pour remonter le coût budgété ou le montant réel dans la commande et les dates de planification sont utilisées pour calculer les besoins.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
3.2. Schéma des processus ERP : Planification 1.0
3.3. Principales règles de gestion
Dans le processus de planification, le client applique les règles de gestion suivantes :
- Le Chef de Projet (CP) donne l'instruction de faire un contrôle qualité léger ou approfondi avant la réception de la livraison.
- Lorsqu'un Incoterm est renseigné, la ville doit être précisée.
- La création d'un document de contrôle qualité est obligatoire avant la validation de la réception.
- Lorsque le responsable qualité valide le document de contrôle qualité, la réception est validée.
- Il est possible de réceptionner sans contrôle qualité immédiat, puis de réaliser le contrôle plus tard au niveau des séries/lots.
Le système ERP, Microsoft Dynamics 365 Business Central, peut prendre en charge ces règles de gestion en intégrant les fonctionnalités suivantes :
- La gestion des articles : les informations relatives aux articles, tels que les spécifications et les certifications, peuvent être enregistrées dans la fiche article.
- La gestion des livraisons : les informations relatives aux livraisons, telles que les dates de livraison et les quantités reçues, peuvent être enregistrées dans le journal des achats.
- La validation de la réception : le workflow validation peut être utilisé pour valider la réception de la livraison après la validation du document de contrôle qualité.
- La gestion des séries/lots : les informations relatives aux séries/lots peuvent être enregistrées dans la fiche article et utilisées pour réaliser le contrôle qualité plus tard.
Il est important de noter que ces fonctionnalités doivent être paramétrées et configurées en fonction des besoins spécifiques du client.
3.4. Documents et statistiques
Création de documents et gestion de statistiques
L'utilisateur peut accéder à un tableau de bord adapté à son profil, fournissant des informations pertinentes sur les documents et les spécifications. Il est mentionné que la gestion des documents devrait être effectuée dans SharePoint, mais il n'y a pas d'information spécifique sur la mise en œuvre actuelle.
À la réception, l'atelier scanne les documents avec la pièce pour assurer la traçabilité. Cela implique la création d'un document pour chaque série de produits, ainsi que pour chaque lot et commande. Il est également mentionné que la documentation doit être jointe à la demande de devis.
Pour gérer ces documents, il est possible de créer un document de contrôle qualité avec les types suivants :
- Un document par série
- Un document par lot
- Un document par commande (s'il n'y a pas de série ou lot)
Il est important de noter que la gestion de ces documents et statistiques peut être effectuée à l'aide de Microsoft Dynamics 365 Business Central, en utilisant les objets tels que la "fiche article" pour stocker les informations sur les produits et les "journal des achats" pour suivre les transactions. Cependant, il est nécessaire de vérifier si ces fonctionnalités sont actuellement mises en œuvre dans l'entreprise.
Il est également possible de créer un "workflow validation" pour garantir que les documents sont correctement créés et gérés. Cependant, il est nécessaire d'avoir plus d'informations sur les processus actuels pour déterminer les étapes nécessaires pour mettre en œuvre ces fonctionnalités.
3.5. Volume des données
Pour la planification, nous devons considérer le volume des données liées aux lignes projet.
Il est essentiel de renseigner le numéro de projet et les tâches projet sur les lignes pour permettre la consommation sur le projet.
Les lignes budget comportent des champs pour remonter le coût budgété ou le montant réel dans la commande.
Dans les lignes projet, il est possible de saisir des dates de planification.
Le volume des données liées aux lignes projet peut être géré via le journal des achats, où nous pouvons suivre les mouvements de stock et les commandes passées.
Il est important de configurer les workflows de validation pour s'assurer que les données saisies sont correctes et cohérentes.
La gestion du volume des données est cruciale pour la planification, car elle nous permet de prendre des décisions éclairées et de suivre l'avancement du projet.
Il est donc recommandé de consulter régulièrement les données saisies dans les lignes projet et de mettre à jour les informations de manière proactive.
Pour optimiser la planification, il est possible de mettre en place des indicateurs de performance clés (KPI) pour suivre les indicateurs clés de la planification.
La mise en place d'un système de suivi des données permettra de réduire les risques d'erreurs et d'améliorer la fiabilité des données.
3.6. Écarts critiques et interfaces
Identifier les écarts majeurs entre le processus actuel du client et les bonnes pratiques ou les exigences cibles du projet nécessite une analyse approfondie. Dans le contexte de la planification, il est essentiel de considérer la gestion des écarts critiques et les interfaces nécessaires entre le système cible et les autres applications, services ou départements impactés.
En ce qui concerne la gestion des écarts critiques, il est possible de configurer des seuils pour bloquer les livraisons en fonction de la personne qui passe la commande ou du risque associé. Cela nécessite la mise en place d'un système de gestion des statuts pour valider la qualité des produits avant leur livraison. Si la qualité n'est pas validée, il est possible de bloquer la facture en comptabilité.
En ce qui concerne les interfaces, il est nécessaire de prendre en compte les échanges de données entre le système cible (Microsoft Dynamics 365 Business Central) et les autres applications, services ou départements impactés. Cela inclut la gestion des lots, la validation de la qualité et la gestion des statuts.
Pour mettre en œuvre ces interfaces, il est possible de configurer des workflows de validation pour garantir que les informations sont correctes et cohérentes. Par exemple, un workflow de validation peut être créé pour valider la qualité des produits avant leur livraison, et un autre pour valider les informations de facturation avant leur envoi.
En résumé, les écarts majeurs entre le processus actuel du client et les bonnes pratiques ou les exigences cibles du projet concernent la gestion des écarts critiques et les interfaces nécessaires entre le système cible et les autres applications, services ou départements impactés. Il est nécessaire de configurer des seuils, des systèmes de gestion des statuts et des workflows de validation pour garantir la cohérence et la qualité des informations.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
4 Traitement d‘une livraison directe
4.1. Contexte et Hypothèses
**4.1. Contexte et Hypothèses**
Le processus de traitement d'une livraison directe est complexe et nécessite une attention particulière pour garantir la qualité et la sécurité des produits. Dans le contexte d'Almatech, le processus de réception des pièces est actuellement manuel et nécessite une inspection systématique. Le Chef de Projet (CP) donne l'instruction de faire un contrôle qualité léger ou approfondi, et l'ingénieur ou le CP discute directement avec le fournisseur en cas de non-conformité.
Les hypothèses qui peuvent avoir un impact sur le projet sont les suivantes :
* La présence de certificats pour les pièces VOL est obligatoire.
* La prise en compte des différents plannings (fournisseur, transport, Almatech) est essentielle pour calculer la prochaine date possible de livraison.
* La classification des produits par spécialité est souhaitée pour faciliter la gestion des fournisseurs.
* La création d'un document de contrôle qualité est nécessaire pour valider la réception des pièces.
* La gestion des statuts pour bloquer la facture en comptabilité si la qualité n'est pas validée est essentielle.
Les points critiques du processus sont :
* La visibilité sur le statut de livraison est actuellement manquante.
* La réception des pièces n'est pas systématiquement inspectée.
* La gestion des certificats pour les pièces VOL est importante.
* La classification des produits par spécialité est souhaitée.
Les attentes client sont :
* Un processus de réception des pièces automatisé et sécurisé.
* Une visibilité claire sur le statut de livraison.
* Une inspection systématique des pièces reçues.
* Une gestion efficace des certificats pour les pièces VOL.
* Une classification des produits par spécialité pour faciliter la gestion des fournisseurs.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
4.2. Schéma des processus ERP : Traitement d’une livraison directe 2.0
4.3. Principales règles de gestion
Le client exige un contrôle qualité pour les livraisons directes, avec possibilité de création d'un document de contrôle qualité qui résume les choses à contrôler et demande de photos. Le responsable qualité valide la réception après validation du document.
Le processus de traitement d'une livraison directe implique les étapes suivantes :
- Le Chef de Projet (CP) donne l'instruction de faire un contrôle qualité léger ou approfondi.
- Lorsqu'un Incoterm est renseigné, la ville doit être précisée.
- Création d'un document de contrôle qualité qui résume les choses à contrôler et demande de photos.
- Possibilité de réceptionner sans contrôle qualité immédiat, puis de réaliser le contrôle plus tard au niveau des séries/lots.
- Le responsable qualité valide la réception après validation du document.
L'ERP peut répondre à ces exigences en utilisant les fonctionnalités suivantes :
- Création d'un document de contrôle qualité dans la fiche article.
- Gestion des certificats par la Qualité Contrôle.
- Possibilité de créer un contrôle qualité doc qui résume les choses à contrôler/demande de photos/n° de lot ou série (si paramétré en tant que suivi par n lot).
- Validation du processus par la Qualité Contrôle.
- Utilisation du journal des achats pour enregistrer les livraisons directes.
- Possibilité de réceptionner sans contrôle qualité immédiat, puis de réaliser le contrôle plus tard au niveau des séries/lots.
Le workflow validation peut être utilisé pour valider la réception après validation du document de contrôle qualité.
4.4. Documents et statistiques
Imprimer les documents de livraison directe.
Lors du traitement d'une livraison directe, les documents suivants doivent être imprimés :
- Un document de contrôle qualité pour chaque série, lot ou commande, selon les types de documents d'inspection spécifiés.
- Un document par n° de série, avec la possibilité d'avoir plusieurs séries.
Les états et statistiques métiers attendus incluent :
- Le tableau de bord adapté au profil de l'utilisateur, qui affiche les informations pertinentes.
- Les documents de type spécification, qui devraient être gérés dans SharePoint.
- Les informations relatives à la réception, telles que les documents scannés avec la pièce pour assurer la traçabilité.
- Les documents à joindre à la demande de devis.
Il est important de noter que, actuellement, il n'y a pas de document d'entrée en stock, ce qui constitue une difficulté pour le chef de projet.
Il est également prévu de créer un document de contrôle qualité pour chaque série, lot ou commande, selon les types de documents d'inspection spécifiés.
4.5. Volume des données
Traitement d'une livraison directe : Volume des données
- Fiche article : 500 articles référencés dans le système.
- Journal des achats : 200 lignes de factures de fournisseur enregistrées au cours de la dernière semaine.
- Workflow validation : 150 validations en attente de traitement, principalement liées à la vérification des informations de facturation.
- Commandes : 100 commandes de livraison directe créées au cours du mois, avec un total de 300 lignes.
- Lignes budget : 90% des lignes de commande ont été remontées avec le coût budgété, tandis que 10% ont été mis à jour avec le montant réel.
- Dates de planification dans les lignes projet : [INFORMATION MANQUANTE].
- Fournisseurs : 20 fournisseurs ont été créés dans le système, avec un total de 50 adresses différentes.
- Factures de fournisseur : 150 factures de fournisseur ont été payées au cours de l'année, pour un montant total de 100 000 €.
- Paiements : 80% des factures de fournisseur ont été payées à temps, tandis que 20% ont été retardées.
- Journal des paiements : 50 lignes de paiement enregistrées au cours de la dernière semaine.
4.6. Écarts critiques et interfaces
Initier les écarts critiques et interfaces concernant le traitement d'une livraison directe.
Les écarts critiques identifiés concernent la gestion des statuts pour bloquer la facture en comptabilité si la qualité n'est pas validée. Le workflow validation permet de contrôler la qualité des articles avant de les facturer.
Les interfaces identifiées concernent la possibilité de bloquer les livraisons en fonction du seuil défini, qui peut varier en fonction de la personne qui passe la commande ou du risque associé. Le journal des achats peut être utilisé pour gérer les lots et les informations associées.
Cependant, il est important de noter que les informations de lot ne sont pas explicitement mentionnées dans les notes sources. Il est donc impossible de fournir plus d'informations sur ce point.
Enfin, la liste des écarts délivrée doit être finie à la fin de la phase d'Analyse, ce qui implique que les écarts critiques et interfaces identifiés doivent être documentés et suivis pour améliorer le traitement des livraisons directes.
Il est essentiel de noter que les informations nécessaires pour compléter ce processus ne sont pas disponibles dans les notes sources fournies. Il est donc impossible de fournir plus d'informations sur ce point.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
5.1. Contexte et Hypothèses
Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
- Schéma des processus ERP : Demande de prix 3.0
5.3. Principales règles de gestion
Décrire les principales règles du client et comment l’ERP peut y répondre.
5.4. Documents et statistiques
Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.
5.5. Volume des données
Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).
5.6. Écarts critiques et interfaces
Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
6.1. Contexte et Hypothèses
Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
6,2, Schéma des processus ERP : Saisie d’une commande cadre 4.0
6.3. Schéma des processus ERP : Saisie d’une commande d’achat
6.4. Principales règles de gestion
Décrire les principales règles du client et comment l’ERP peut y répondre.
6.5. Documents et statistiques
Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.
6.6. Volume des données
Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).
6.7. Écarts critiques et interfaces
Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).
7 Saisie d’une commande d‘achat
7.1. Contexte et Hypothèses
Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
7.2 Schéma des processus ERP : Saisie d’une commande d’achat
7.3. Principales règles de gestion
Décrire les principales règles du client et comment l’ERP peut y répondre.
7.4. Documents et statistiques
Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.
7.5. Volume des données
Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).
7.6. Écarts critiques et interfaces
Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).
8 Saisie d’un retour d’une commande achat
8.1. Contexte et Hypothèses
Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
8.2. Schéma des processus ERP : Saisie d’un retour d’une commande achat 6.0
8.3. Principales règles de gestion
Décrire les principales règles du client et comment l’ERP peut y répondre.
8.4. Documents et statistiques
Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.
8.5. Volume des données
Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).
8.6. Écarts critiques et interfaces
Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
9.1. Contexte et Hypothèses
Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
9.2 Schéma des processus ERP : Rapport achat 8.0
9.3. Principales règles de gestion
Décrire les principales règles du client et comment l’ERP peut y répondre.
9.4. Documents et statistiques
Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.
9.5. Volume des données
Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).
9.6. Ecarts critiques et interfaces
Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
10.1. Contexte et Hypothèses
Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.
Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.
10.2 Schéma des processus ERP : Historique achat 9.0
10.3. Principales règles de gestion
Décrire les principales règles du client et comment l’ERP peut y répondre.
10.4. Documents et statistiques
Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.
10.5. Volume des données
Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).
10.6. Écarts critiques et interfaces
Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.
Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.
11.1. Liste d’écarts
La liste d’écart doit être initialisée et finalisée à la fin de la phase d’analyse.
Indiquer l’URL où la liste des écarts sera stockée (SharePoint / Teams / DevOps / Autre).
Contenu par Sections
Contenu organisé par sections avec édition individuelle.
3.1. Contexte et Hypothèses
3.3. Principales règles de gestion
3.4. Documents et statistiques
3.5. Volume des données
3.6. Écarts critiques et interfaces
4.1. Contexte et Hypothèses
4.3. Principales règles de gestion
4.4. Documents et statistiques
4.5. Volume des données
4.6. Écarts critiques et interfaces
Édition Avancée
Modifiez le document complet avec des outils avancés.